Presence is a service that allows communicating devices to publish their current presence information and fetch the presence information of other users connected with a communication network. Presence information is exchanged using IETF simple based PUBLISH, SUBSCRIBE, and NOTIFY messages in a communication network. These messages are periodically sent between subscribed user equipment (UE) and a server to keep presence information up-to-date. The frequency of these messages is an engineering compromise (typically 1 hour) between network traffic and the validity of presence information.
In conventional examples, users may travel into and out of a network coverage area and may become temporarily or permanently inaccessible. When a user becomes inaccessible, presence information about that user may remain incorrectly published due to delays in updating presence information on a communication network. Thus, a user may appear “available,” but a call cannot be established because the user is, in fact, “unavailable.” This disparity may contribute to a perception that all presence information is unreliable. One way to address this problem is to increase the frequency of presence updates. However, this is an obvious but expensive solution to the problem.
At least two message delivery failure situations are possible candidates for a proactive presence update from the server itself. These situations and some corresponding strategies for achieving more accurate presence information are presented herein. Utilizing embodiments describe herein may not only improve user confidence in presence information but also optimize message traffic in a communication network. In addition, changes proposed in embodiments herein, are within the existing OMA-based presence framework. As such, methods for managing presence information in a real-time communications network are presented herein.
Presence specifications, standards and requirements are discussed in greater detail in the following technical specifications from Open Mobile Alliance (OMA), which are hereby incorporated by reference in their entirety:
OMA Presence SIMPLE specification, Candidate Version 1.0-10 Jan. 2006; and
OMA PoC Control Plane, Candidate Version 1.0-27 Jan. 2006.
Other references pertinent to this patent application are also the following specifications from the Internet Engineering Task Force (IETF), which are hereby incorporated by reference in their entirety:
IETF RFC 3863 PIDF—Presence Information Data Format; and
IETF RFC 3903 Session Initiation Protocol (SIP) Extension for Event State Publication.
PTT System Overview
FIG. 1 is an illustrative prior art representation of a PoC System Architecture in accordance with OMA PoC/PAG version 1 specifications. An OMA PoC system architecture 100 includes User Equipment (UE) 102 and a set of network components. As illustrated, UE 102 contains the necessary pieces to interface the user acting as participant in a PoC session under the OMA version 1 specifications. UE 102 can either be a mobile terminal, a PC or any other device connected to the access network. Device Management (DM) client 104 inside UE 102 is used to bootstrap UE 102 with necessary configuration data from a DM server 116. An XML Document Management Client (XDMC) 110 is used to download and update by request any relevant contact lists stored in Shared XML Document Management Server (XDMS) 122. An Aggregation Proxy 124 may be configured to perform the authentication of any such requests. Similarly, the XDMC 110 is also configured to communicate via Aggregation Proxy 124 with PoC-specific XDMS (PoC XDMS) 126 for the purpose of managing group policies and authorization lists. UE 102 further includes Presence Source 106 and Presence Watcher 108. Presence Source 106 may be configured to publish a UE's availability status to other users. Presence Watcher 108 may be configured to retrieve availability status of others (e.g. other UEs and contacts). Both UE presence entities communicate with Presence Server 120 via a SIP/IP Core 118. In an OMA PoC system built on top of a GPRS radio network, a SIP/IP Core is often a IP Multimedia Subsystem (IMS) as standardized by the 3rd Generation Partnership Project (3GPP).
A PoC client's main responsibilities are: session management, SIP registration, TBCP request-response management, media transmission, and media reception. Under existing standards, session management, SIP registration may be accomplished over POC-1 and POC-2 interfaces 132 and 136 respectively. Furthermore, TBCP request-response management, media transmission, and media may be accomplished over POC-3 interface 134. PoC server 128 is responsible for application level network functionality including PoC session establishment, termination, handling of TBCP messages and media switching between the participating clients.